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ABSTRACT 


This project develops a framework to permit the intvoduc- 
tion of combat effectiveness as a high level objective func- 
tion to the naval ship design process. This is effe ted by 
the development of a model of the sources of ission 
requirements Lor the design. Interaction and 
inter~connection of the design stages is provided by design- 
ing the model around the menu-oriented software system known 
as DEX (Decision Executive System). 


The model used the commonality of its" design and the DEX 
commands and prompts as the means of inSuring that all par- 
ticipants to the design process have access to the assump- 
tions used to develop combat effectiveness as an objective 
function. The possible capabilities of the model are exhib- 
ited through Simple examples which show the extreme 
Sltuation dependency of combat effectiveness assessments. 
The possible implications of the use of the model for future 
research in Naval Architecture/ Marine Engineering «re dis- 
cussed. 
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CHAPTER 1 


INTRODUCTION TO THE PROBLEM 


The objective of this work was to establish a set of 
independent variables to describe a mono-hull surface 
combatant ship (naval vessel) and to determine its mission 
effectiveness. This determination will be made at the fea- 
Sibility stage of the design and will be dependent upon the 
environment in which the design 18S to operate. It was 
determined that all variables would be specified by their 
contribution to specific missions. It was expected that the 
determination of these contributions would eventually permit 
an evaluation of the designs’ combat apeceeivane so: As in 
any large scale system definition, the question of appropri- 
ate level of detail was Boh Gherale This project will attempt 
to specify these independent variables, both in number and 


in detail, sufficiently to permit determination of: 


1. feasibility under known or assumed technological and 
budgetary constraints 


2. combat effectiveness 
3. non-combat mission effectiveness 


4. cost effectiveness. 





Progress in the development of this set of independent 
variables was, initially, very uneven. The first problem 
was to establish a complete listing of all missions for such 
a ship. It was determinted that the best existing list of 
this sort would be a good point of departure for this prob- 
lem. Research toward finding such a document eventually 
lead to a publication entitled Naval Warfare Mission Areas 
and Required Operational Capability, also known as OPNAV 
imict. 3SO01. 25. This instruction is used to indicate which 
mission areas, of all possible U. S. Navy missions, have: 
been assigned to a particular class of vessels. It also 
lists the assigned missions by the portion of the ships' 
organization (operations, Se eeaingreces: which the 
mission is assumed to affect. As such, this instruction is 
an excellent attempt to describe all missions which a par- 
ticular ship 1s "expected" to be able to perform when 
properly (fully) manned and when all installed equipment is 


fully operational. 


The possible missions listed in OPNAV Inst. 3501.2E could 
be broadly separated into two categories; combatant and 
non~combatant. Within this instruction, the descriptions of 
the two types of missions are quite different. A typical 
noncombat mission entry might be described as "Search and 
Rescue", with the the equipment and training levels for the 
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ship and crew being specified. Conversely, A typical combat 
mission entry might be "Force and Area Air Defense", and 


would generally be without any further explanation. 


This "“underspecification" of many missions within this 
publication is most clearly shown in the listing of many 
general combat missions. In our previous examples of Force 
and Area Air Defense, the problem with the statement of the 
mission is that it 1s, in addition to being somewhat subjec- 
tive, very "relative". It 1s most relative to the forces 
which might be attempting to defeat the proposed defense. 
It is also dependent, among other things, upon which other 
ships are in company. In short, the whole mission area can 
only be defined in terms of a broad spectrum of possible 


Situations. 


Since the non-combat mission area assignments in OPNAV 
Inst. 3501.2E were considered satisfactorily specified, this 
publication was chosen as_ the basis for the selection of 
hardware resources necessary to perform those types of 
missions. The combat mission areas, however, were not 
defined well enough within that instruction to be used to 
determine the direct effect of the missions upon the ship 
and its' systems. Therefore, it was necessary to establish 
a methodology within the model which would permit sufficent 
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‘description of combat type missions. This framework was 
intended to provide that definition by allowing the mission 
to be described in terms of the operational environment 
within which the ship would be designed. This environment 
will include the contributions or detriments to combat 
effectiveness created by man-made and natural situations 
which the design might encounter in combat. Later, it was 
found that this "threat and environment" model would form 
the foundation for the evaluation of combat effectiveness of 
a ship. It must be kept in mind that both the platform and 
the payload were being, thusfar, described only in terms of 
what they must do. We were carefully avoiding any attempt 
to define the missions in terms of the means to be used to 


accomplish them. 


Now, we may address the various independent variables 
defining our theoritical ship in terms of the requirement 
but more importantly in terms of the source of the require- 
ment. The other two major sources of naval ship mission 
requirements were assumed to be; 1. Non-combat mission 
requirements - it was assumed that the requirements of OPNAV 
Inst 3501.1E satisfactorily listed these. 2. Estimated 
time/cost requirements; which might be considered a form of 
filter to the first level feasibility of the conceived pay- 
load. If all possible sources of the defining parameters 
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can be identified then we may be assured of addressing 


requirements in the construction of our model. To this 


point we have identified the types of vessel requirements as 


follows; 


REQUIREMENT SOURCE 


-~-Combat Payload --Opponent, Environment, Force 


a in company 


--Non-Combat Payload ="Ua S.. Navy, (through Soeuery 


Equals "PAYLOAD" 


In the same vein; 


REQUIREMENT SOURCE 
-~-Payload --as above 
+ 


for payload 


~-~Platform Parameters ~-Naval Architect as 


Meuals "SHIP" per guidance provided 


by others 


The assumption made to this point is that, 1£f the 
requirements of the different "Sources" of ship character- 
istics could be clearly and completely defined, we could 
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translate these requirements into hardware; that is a ship. 
Even if we were entirely successful in this difficult trans- 
lation, we would be left with two important questions. 1. 
How “efereyel & was the ship we had created? 2. What 
technique(s) could we use to permit timely processing and 
data manipulation of the numerous items which must be 


included in even the simplest of ships? 


The answer to the question of assessment of the "quality" 
of the designed ship depends in large measure, upon the 
assessors' definition of "goodness". In other words, it 
might well change with a change in assessor. With this in 
mind, the next logical step in the development of our model 
would be a tabulation of all significant measures of surface 


combatant vessel "performance". 


Previous ship synthesis models (we will roughly define 
SSMS aS computer aided interconnection of the various ship 
design sub-stages) have focused upon the "non-combat" type 
performance measures. Toward the assessment of such items 
as cargo carrying capacity, rates and costs and even total 
"life cycle" costs, these models have made significant 
progress. In our case, we have, with the development of 


the combat situation framework, provided, in theory, the 





information necessary to conduct a measurement of combat 


performance within the design process. 


Model Outline 


We can now look at the "flow chart" describing our 
approach to designing a Mono-hull surface combatant and the 


assessment of that design. See figure 1. 


As will be recalled, the general approach was to , first 
account for the different independent variables "driving" 


the design, by source. Referring to figure 1 these were; 


The environment in which it would perform the "combat" 
missions (1a) 


The "non-combat" missions to be performed (1b) 


fiememacerial and financial resource considerations of 
both missions (ic) 
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The simple identification of these requirements is a nec- 
essary but not sufficient step in the total design of a ves- 
sel. We must, then identify the "blend" or "mixture" of the 
hardware items created by those requirements into a measure 
of "goodness" Or more COERCet ly a "measure Cr 
effectiveness". More precisely, we will look at the problem 
as a determination of the resultant effectiveness of a spe- 
cific combination of the variables.This determination was 


made using utility theory (see chapter 5) 


The major synthesis steps, as provided for in this model 


would be; 


Translation of mission requirements into a payload (T1) 
Translation of platform parameters into a "ship" (T2) 


Estimation of the ship in terms of non-combat perform- 
ance (E11) 


Estimation of the ship in terms of combat performance 
(E2) 
Model Design Philosophy 
Before describing the model in detail, we will discuss 
the "design philosophy" of the model. The following charac- 
teristics were determined to be the most important in the 
development of the model. 


ale "Performance" Based 


rae Computer based with the DEX software (see chapter 2) 


ata 





Si Highest level development 


Performance Based 
Most existing ships synthesis models might be best described 
as the "one shot" method, where the objective becomes the 
Satisfaction of a set of given requirements. These are usu- 
ally the ability to carry a certain amount of equipment, or 
perhaps, some type of vessel charactertics such as geometry 
and powering. The problem with this type of approach is 
that the input is considered invioliate and the user can not 
regard any violation of assumptions made at an earlier stage 
of the design which lead to these conclusions. An associ- 
ated problem with this approach 1s that to reach such a 
State of specification the user most likely conducted much 
preliminary work prior to exercising the model. In short, 
much of the most involved design work has been conducted 
external to the possible assistance of the computational and 
data storage/retrevial abilities of the computer. A third 
problem common to most existing models is the virtual lack 
of interaction. The essentially batch or "one-shot" method 
used in most adequately-supported models requires the entire 
process to be repeated to discover the effect of any 


changes. 


As bothersome as the perviously described shortcomings to 


existing SSMS might be, the lack of adequate effectiveness 
a2 





measurement 1S far more serious. Most common measurements 
are implicit co-relationships of displacement, fuel or man- 
ning levels to cost. Such variables are,indeed, important 
to the peace time portion of the life of the vessel. They 
aor not, however, address the true reason for existance of 
the combatant, that is its performance in combat, itself. 
Historically such an assessment has , at best, been con- 
ducted totally separate from any non-combat performance 
evaluation. In the most common practice, any combat system 
design performance evaluation is conducted on a single sys- 
tem by system basis without any integration of the system 
resource requirements upon the vessel design. For example, 
the performance evaluation and resource requirement iden- 
tification for an anti-air missle system would not address 
any impact of those resources upon the performance of, say 
the anti-submarine weapons suite. In truth, the earliest 
time a total design is subjected to a combat performance 
analysis is usually after initial fleet introduction of the 
design. At this point the ship is "Synthsized" according to 
its "major" characteristics and modeled by interested activ- 
ities. These models are then "gamed" against similarly 
conceptualizsed opponets. Two important points should be 
noted. First, this process is done after we have paid full 
price for the vessel without the opportunity to correct any 
discovered weaknesses prior to completion. Second, the 
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information of how the "modelers" "fought" the ship is not 


retained. 


Peewee be the implicit assumption of this effort that 
the proper assessment of a combatant ship design should 


include an internal estimation of "combat effectiveness". 
DEX as the computer software package 


Given the necessity for computer aid in the modeling of 
the complex ship design process, the choice of operating 
software becomes critical. The major characteristics of the 
DEX (Design Executive) system, chosen for this model, are 
included in chapter 2. Also included in that chapter are 
the effects of those DEX characteristics upon the capabili- 


ties of the model. 
Highest Level Development 


In the development of any model, the selection of the char- 
acteristics which will be used to describe the modeled enti- 
ty is critical. The challenge is to include all necessary 
eheracteristics and no unnecessary ones. In the development 
of this model, an attempt has been made to identify all 
those variables needed to formulate the problem at the fea- 
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Sibility level. It is intended that the model provide for 
the inclusion of all variables which could, at this feasi- 
bility level, affect the evaluation of the designs’ combat 


effectiveness. 


Is 





CHAPTER TWO 


The Design Executive System (DEX) 


The methodology for this model was designed to be 
installed within the Design Executive System (DEX) under 
development at Massachusetts Institute of Technology and the 
University of Mighigan. DEX is a self-contained software 
package which is adaptable to almost any computer system 
Slieeorting fortran. It provides a system for running task 
based programs, called "modules". Primarily, DEX supports 
interactive programs and it srrovides this interaction by 
communication between five "parties". These parties are; 
ae The user 
oa The computer 
3. The computation program 
4, The source of the input 


5. The destination of the output 


The degree of active involvement with DEX is within the pre- 
rogative of the person writin; the particular application 
program. That is the "module author" may choose which DEX 


Services to use 


There are five major characteristics of DEX: 


i. The user is in the design loop. 
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DEX allows the design process to be executed in more 
than one sequence. 


DEX "talks" to the user in plain english. 
Dee 1S “forgiving”. 


DEX has multiple capabilities for input and output. 


ty 





a The user is in the design loop. The ship design spiral 
vividly demonstrates the strongly iterative nature of the 
Ship design process. The ability to perform data manipu- 
lations to a specific point and, then, analyze those results 
to decide where or if to proceed is vastly preferrable to a 
SEaLOugmeput” Operation. DEX enables the user to choose a 
new path, obtain new information or to edit and insert 


information before it is used within computation sections. 


2. DEX allows the design process to be executed in more than 
one sequence. This 1S accomplished by providing the user 
with a scheme for generating menus within his application 
program. The use of "menus" to provide the user with a 
range of choices of possible decision paths toward his goal. 
A menu is a list of options (with a current maximum of 12 
per menu) from which the user chooses to either define a 


data value or proceed to the next step of the operation. 


An example of a menu is included in figure 2. If the 
user desired to specify or identify a type of weapon from 
this menu, he would type in sufficient characters to unique- 
ly identify that weapon within that menu. Examples might be 
"ct" for torpedo or "aa.m" for AA.msl. The subprogram would 
accept this choice, if valid, and execute the segment of the 
program that is logically associated with the menu choice. 
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Weee Ine GUN 


TORPEDO 
AA.MSL 


ZeU.MSL 
ASW.MSL 


fo Calling 
Sub program 





FIGURE 2 








If the entry is not valid, the user will be prompted, again, 
for an entry from the same menu. It is not necessary that 
the menu, itself, be displayed. If the user is familiar 
with the choices within the menu, he might be prompted to 
make a choice, from memory, by seeing displayed 

*enter an item from menu-wep.type 


If however, the user does not know the choices of this menu 
he could type 


§ display menu-wep.type 


to have the menu displayed by DEX. 


Note the use of "done" as the last menu item in figure 2. 
A sub program with a menu containing "done" returns to the 
sub program which called it only when "done" is selected. 
Without "done" the control of the program is automatically 
returned. Such a menu, therefore, can only have one choice 
made at atime. The user is free to choose menu item(s) as 
desired. This means there is no predetermined path through 
a group of related of "stringed" menus, the user specifies 


the path. 


a, 





3. DEX talks to the user in plain english. The menus, mes- 
sages and questions to the user generated by DEX have been 
specifically designed to be as easily understood as 
possible. The instructions which the user must supply are 
intended to be as nearly "conversational" in nature as they 
could: All dialoge encountered by the user has also been 
Standardized within the DEX modules as much as possible to 


reduce learning effort when using a new program. 


4. DEX is forgiving. Because of the extended "pathing" of 
DEX, there 1s considerably more "mental discipline" required 
in its' use. Because of this additional "thinking" the pos- 
Sibility of error is also increased. These errors PS lh 
range from inadvertently depressed keys, to errors in 
desired process. When existing sections of DEX and its 
library routines were developed, as many potential errors 
and corresponding diagnostic messages as possible were 
anticipated and included. When an error is detected control 
is always returned to the user for resolution of the error 


without interrrupting the execution of DEX or the module. 


5. Multiple input-output capability. DEX is designed to 


permit communication between; 
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1. Data Bases 
Pe Disk Files 


3. Terminal screen for alphanumeric characters or graphics 


In general, the DEX operating environment may be 
described as having a total of five "sources" of information 
and four information "destinations". The term "information" 
is used in preference to input or output to reflect the 
duality and inter-changability of these two processes. For 
this reason, the author will apply the term "information" to 
variables which might be input or output, as values having 


Source Or destination. 


The sources and destinations for information provided 


within the DEX operating environment are: 


1. DEX-created data bases 


2. The user via terminals using DEX routines to read or 
write alphanumerics 


3. The user via terminals or plotters using graphics to 
read or create x-y co-ordinate plots 


4, Sequential files 


5. Module default (source only) 
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The user may use a different type of destination, as his 
source may use different sources for information. For exam- 
ple, the user might read information from multiple data 
bases and write the information to another terminal or a 
file Oo beth. The only restriction is an essential 
out-growth of logic; a module can be directed toward only 


one source or desStination at a time. 


As may be obvious, DEX offers considerable improvement in 
facilitation of interactive design process management. It 
is designed to be consistent and flexible, providing "room" 
for the required magnitude and differing forms of informa- 


tion, processes and paths required in modern ship design. 


An explanation of DEX sufficient to develop the reader 
into a proficient DEX user will not be included in this 
paper. An excellent reference toward that end, however, is 
An Investigation Mg iee the Use Of Data Bases in 
Computer-Aided Design, by LT Richard Celotto, USN 1981. It 
will be necessary to describe the major terms used in the 


System to permit easy reference. 


DEX consists of three levels of programs: 
1. DEX proper- These several hundred subroutines provide 
the operating "umbrella" of DEX. These subroutines are 
designed to provide a uniform appearance of the system 
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to the user of the various modules. In general, they 
provide consistent input-output and data manupulation 
capabilities throughout the system. 

2. Extented DEX library- this is a collection of 45 subrou- 
tines and general functions designed to facilitate the 
construction of a module with a program specific 
purpose. These include; reading, writing, editing, unit 
conversion, and messages and status indications. 

3. Module- A module is a complete set of subprograms writ- 
ten and executed together to perform a specific task. 
It may only have one program or it may have many addi- 


tional subprograms employing menus to take full advan- 
tage of DEX and any extended library functions desired. 


One concept of DEX is critical. DEX identifies a vari- 
able within a data base by its name and not by its location. 
To use this capability, the data base nese be properly con- 
structed by the use of the command in the DEX proper main 
menu "DBEDCMDS" or the data base management routines listed 
ice loto pg 30. Once these format rules have been 
observed, arrangement of variables within the data base may 
be made without regard to sequence. Thus, for example, if a 
user needed the value in a data base corresponding to a 
ships length, he might retrieve that value at address 
SLengen™ . He would not have to specify (or know) that the 
desired value is in the fourth or tenth entry in the data 
base. This is a powerful and new approach and it ‘permits a 
user unfamiliar with a specific data base to obtain included 


information with much less prompting instruction. 


Zs 








Another very important feature, a feature absolutely 
Critical to an interactive process, is that it can be edited 
from within DEX but outside a user module. This capability 
allows the uSer to over-ride, if he desires, a program cre- 


ated result and input, directly, an alternative. 
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CHAPTER 3 


Section Development Example 


This chapter will outline the techniques used to develop 
the sections outlined in chapter 1. The section chosen for 


this explanation is "Threat and Environment". 


The initial work within each section was to research the 
general topic; in this case the natural operating environ- 
ment and the possible combat threats which our design might 
encounter in the performance of its assigned missions. In 
the beginning of the effort it was important to be alert to 
any and all information on the subject. Thus, the earliest 
work was directed to put the widest possible bounds about 
the area. In this early stage, the best source of these 
boundS waS conversations with leading academic and profes- 
Slonal experts in the field. Other early sources included 
professional journals, proceedings of applicable societies 
and unclassified professional development publications for 
United States Naval officer warfare specialty qualfication. 
In this section, We began with the three classic threats; 
air, surface, and sub-surface. Literature alerted us to the 
necessity to include land based targets as a potential 
EMceat" Later, conversations with "experts", especially 
"wargaming" types, proved that certain aspects of weather, 
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general jamming environment and the use of decoys were all 
matters which could have major impacts upon threat develop- 
ment. Through an involved iterative process the following 
seven areas of "environment and Threats" were proposed and 


accepted as inclusive. 


1. SURFACE- surface ship and mine threats 
2. SUBSURFACE- submarines, swimmers and submerged mines 
3. AIR- aircraft or missiles 

. LAND-~ missile sites or cities 


= 
9. JAMMING 
6 


» DECOYS 
7. WEATHER- environment including temperature, seas, 
visability 


At this point, the first order parameters of the "Threat 
and Environment" had been identified. Attention was then 
directed toward specification of the independent variables 
defining each of these seven areas; the sub-elements, 1f you 
will. imemmepLocecosmeGcccoribead Lor the determination of the 
threat environment was repeated, in scale, for the identifi- 


cation of the factors constituting each of them. 


The investigative method used in the detailed development 
of each section investigated in this report was: 
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1. An initial estimate of the elements was made. 

2. A literature review of both classified and un-classified 
sources waS conducted to provide a first refinement of 
Eoe iumMitial list. 


3. Private enterprise and military experts were consulted 
tofurther refine the list. 


4, The initial framework of the section was established. 

9. The team worked with the thesis advisor and contempories 
to confirm that the included elements had proved major 
impact upon the next higher level 

definition of our design. This work also ensured that 


the arrangement of the variables could be efficently 
implemented within the DEX framework. 


A discussion OE what was, and perhaps just as 
importantly, what was not, included in this example section 
should be provided to demonstrate the process. In the case 
of overall combat Situation definition, it was considered 
essential to include the elements which aided the ship, as 
well as the "threat". Therefore, this section would have to 
permit the presence and effect of friendly or aiding ships, 
aircraft oor any other such elements as positive contrib- 
utions to the operating Situation. It was decided to assume 
that, in the absence of information to the contrary, each 
Side (them or us) had any capability known to be possessed 
by either. This is a conservative assumption but is impor- 
tant for several reasons: 

development of either side as a complete model, automat- 


ically models the opposition. 
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most operational commanders will make such an assumption 
in the employment and operation of their ships. 


In the case of our example section the next step after 
identification of the seven major areas was the identifica- 
tion of the subelements to each area. In the case of "air 
threats", the author's initial estimate of the appropriate 


subelements to "air threats" was: 


We SPEED 

te ALTITUDE 
or. NUMBER 
a. SIZE 


5. DECOYS 


From several visits to the U.S. Naval War College and 
from discussions with personnel in Washington, D.C. con- 
cerned with weapons system development and intergration, 
this list was modified as follows "speed" became two speeds; 
inflight speed - the normal "cruising" speed of the threat, 
and "terminal" or final speed of the threat as it made a 
final approach to the target (in this case us!). Although 
some weapons entire flight was conducted at a single speed, 
it is much more common for the majority of distance from 
launch to target to be conducted at the relatively lors speed 
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to ensure & maximum range. Typically, the threat will then 
conduct a radical altitude change manuver such as a "pop up" 
from a low altitude approach or a "dive" from a high alti- 
tude approach to effect a high “terminal” speed attack upon 


1ts target. 


In addressing the problem of multiple targets, ("number" 
in the original list) it became quickly apparent that the 
threat could have density in both space and time. Thus, the 
type of "counter" mounted to raids of different sizes and 
time/spatial separation was quite different. These threats 


must be allowed to be accounted for Separately or together. 


ESrze" eruielkeley: proved to be a totally inadequate 
description of the "visibility" of the threat to sensors and 
was quickly replaced by "signatures". Thus the list had 
changed, over a period of research and refinement as 


follows; 
Air Threat Elements 
SPEED In flight speed 


Terminal speed 
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NUMBER Target density (time) 


Target density (Space) 


ALTITUDE Engagement envelope 
SIZE Signatures 
BECOYS Decoys 


In the work on the subsurface threats there were like 
decisions tc be made which will be discussed to show some of 
the early discisions necessary for applicability or magni- 


Bude consid<-rations. 

At the stage just reached in the listing of important 
"air threat elements", the applicable "Subsurface threat 
elements" were assumed as follows: 

Subsurface Threat Elements 


SPEED 


RANGE 
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SIGNATURES Radiated noise 


AeCOuctdeGmerocsmseeti1on 


BaCOYS 


In comparison to the air threat development at the same 
stage, some significant differences are apparent and should 
be explained. There is no subsurface counterpart to either 
altitude or density. In the case of depth (subsurface anal- 
ogy to air altitude) detection or destruction of subsurface 
threats was assumed to not be affected, to a first ecrder 
level, by the depth of the target. This is a good example 
of the type of assumption which may be completely reasorable 
at a certain technology level (point in time) or for a spe- 
cific type of analysis, but which must_ be clearly and 
completely documented. Such documentation 1S mandatory so 
that, should the factors justifying or allowing such a sim- 
plification be altered for any reason, the model can be 
reconfigured to include the new and now driving consider- 
ation. In our example the omission of threat density for 
subsurface threats reflected current tactics of single ship 
action, vice World War II wolf pack type operations. Such a 
methodology even today may be highly suspect for mine field 
operations. Speed is included in the list because there is 
a wide range of relative target speeds. That 1s to say that 
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the weapons used to counter such threats are, typically 


working on the extremes of their capabilities. 


The remaining sections of the threat/environments devel- 


oped to equal degree as those just discussed were then: 


Surface Threat Elements 


SIZE 


RANGE 


@ 


SIGNATURES 


DECOYS 


Size was distinct from signature to account for 
Survivability differences between vessels. Most existing 
algorithmns for survivability are based on overall length of 
the vessel in question. Note that speed is not included for 
Surface threats. This 1s because the relative speed range 
of all possible surface threats 1S so small compared to the 


typical weapons used to counter it. 


Land Based Threat Element 
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Land based targets are included as a significant factor in 
payload requirements because the destruction of them is a current 
mission of some U.S. Navy surface vessels. They are, in effect, 
an “anti-threat". 

SIZE 


RANGE (TO) 


HARDENING (the degree of protection provided the site) 


@ 


Jamming Elements 


NOISE (electromagnetic energy density) 


CHAFF (physical interference with electromagnetic transmission by 


use of metal foil ribbons or pieces) 


Weather Elements 


VISIBILITY (unaided vision) 
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ELECTRICAL Disturbance (lightning, sunspots, etc) 


TEMPERATURE 


SEAS (height, period, direction) 


AS might be expected, the next stage in the “top down" 
development process was to "brainstorm" the elements which 
directly and significantly effected each of the threat area 
elements. For example, it was necessary to determine what 
factors "defined" the signatures of a surface threat. A 
good initial approach was to identify such signatures by 
type transmission medium, i.e. air or water borne and to 
further break down these mediums by the types of energy 


Eeansmitted within them: 


Air Borne 


Electromagnetic (energy emitted from on board equipment) 


Visual (reflectivity, color, roughness) 


Heat (infra red energy emitted) 


Noise (acoustic, air borne; used in detection only) 
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Radiation (sub-atomic particle air borne) 
Water Borne 
_Radiated Noise (generated in the operation of the platform itself) 
Sensor Noise (acoustic, water borne, from sensors) 
Radiation (sub atomic particle, water borne) 
Wake (physical disturbance to normal ocean conditions) 


It is at this stage that we are truly making some 
progress toward our goal ; the identification of all major 
independent variables defining the performance of a surface 


combatant. 


This is an excellent place to point out one of the more 
basic errors made and the reasons for it. One of the air 
threat element identified was engagement envelope. This 
attempt to describe the threat in terms of the magnitude or 
means of the counter to that threat. In other words we were 
artifically defining both the threat and some of the parame- 


ters describing our counter to the threat by defining the 





volume of space around out ship which we would "defend". 
The effect was to be describing the payload required in 
terms of desired or precieved performance as an input. This 
1s not what the model was developed to accomplish. The idea 
was to input (or define) what must be countered by the com- 
bat systems payload and have the model, through a fully 
developed and broadly considered program provide appropriate 
means to actually "defeat" the inputed threat. Therefore, 
this approach was abandoned and the orignal premise of defi- 
nition by need, not means was begun for the air defense 
problem. The final list can be foundstarting on page IAI of 


the Appendix. 


Another major omission of the threat/environment section 
as thus far developed was the omission of the difference 
between weapon and weapon platform as distinct but related 
MaGtOrS . It was not sufficient to address, for instance, 
attacking missiles themselves. It is entirely possible and, 
in fact, most desirable to disrupt the air borne threat by 
"defeating" the weapons carrying platform prior to weapons 
release. We must, therefore, provide within our model, for 
the total of all elements which make up the weapon, the 
weapons carrier and finally the two together. This error of 


omission would be fundamental. 
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From this level of detail on, the major problem was of 
flow - cause and effect of each stage upon the other. The 
Subsection of the example threat and environment menu which 
was fully developed was the "Surface threat". A detail 
listing of all developed menus is included on the first page 
of the appendix. The next chapter will discuss this sub- 


section in greater detail. 
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CHAPTER 4 


DEVELOPMENT OF THE OBJECTIVE FUNCTION 


This chapter will offer the methodology for the develop- 
ment of the function used to assess the design. Each menu 
string in this model was designed to establish a hierarchy 
of parameters. That 1S within a given string, the elements 
defining a parameter are, hopefully, "downstream" of the 
things they are defining. However, at each menu level there 
are perhaps as many as 8 to i0 different parameters of equal 
Status, all defining the next higher menu iten. For 
example, returning to our example menu of chapter 2, we see 
that there are 4 possible weapons choices for the designer. 
How would the designer (model user) choose how many of each 
type weapon should he incorporate within his vessel? The 
ability to choose the proper or desired combinations of such 
things as fire power, speed, endurance, survivability or any 
of many other characteristics is essential. It must be 
remembered that, in general, these characteristics compete 
for vessel resources such aS space, weight or manpower with- 
in a design. The remainder of this chapter will discuss two 
possible methods, for singular or combination use, for this 
important question, specificially; given that the model (or 
any model) has identified the pertinent independent vari- 
ables in naval ship design. How do we decide how much of 
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each is best? Or in other words; given the decision vari- 


ables; what 1s the objective function? 


The two techniques offered will be; 
Poeeocllity Theory 


B. Artifical Intelligence 


OC Peo Ws Oly. 


We will demonstrate utility theory rather than define 
tt, Things are "worth" more or less to an individual (or 
decision making group) depending upon the circumstances at 
the moment of evaluation. Take something as seemingly well 
Sereaotisnea as the worth of a dollar. If you have $50.00 in 
your pocket, a dollar does not necessarily have too much 
value. If, however,you only need $.60 to ride the subway, 
but have no money at all, a dollar is something you could 
really appreciate One way of explaining this is to think 
O@eemeeUtrlity of a Goillar in each case. Another dollar, af 
you have fifty, 1S not too useful to your desire to go home. 
[ifeEnewiatterc instance, that Gollar has great utility if you 


want to avoid walking. 


Utility theory is one important consequence of the axioms 
of rational behavior. A person who accepts the axioms 
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wishes to make his own decision processes consistent with 
them. To do so, he must always select decisions so as to 
Maximize the expected utility of their outcome. The fact 
that it is the expected value of his utility which he must 


Maximize 1S a consequence of the laws of logic themselves. 


We will initially limit ourselves to the case where a 
Single quantitative attribute, x, 1S considered by the deci- 
Sion maker to be an adequate description of the possible 
total consequences of his decision problem. Also, for sim- 
plicity, we first assume that the decision maker prefers 
larger values of x to smaller values. These restrictions 
(single numerical attribute, preference for the larger of 


two values of that attribute) will be removed later. 


Reference Lotteries and Indifference Probabilities 


Let x Fe 


1 ,»~. be the particular values of our single 


2 
G@u@emtitative attribute, x, which apply to the consequences 
of the decision problem. Let x* be some quantity as large 
or larger than the largest of the x. 'S andae tx eo auals 


' 


tity as small or smaller than the smallest of the x. 'S. To 
determine the utility of each x, (and therefore of the con- 
Sequence described by x ), we first establish the reference 


liemeeryeot the form Shown in Figure 4.1, such that the deci- 
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Sion maker is indifferent between ownership of this lottery 
and obtaining the consequence of value x . This requires 
the measurement of p(x. ), called the "indifference probabil- 


ity” for a consequence of value Xs. 


A utility U(x,) can then be assigned to each consequence 
Such that 
U(x, ) = ki + k2 p(x, ) 
where ki 1S any constant and k2 is any positive constant. 
For instance, if we set ki = 0 and k2 = 1, we may use the 
indifference probability itself as the measure of utility 


for any consequence. : 


Operationally, the procedure is not so useful, because it 
‘is difficult to assess the p(x, )'s. A decision maker finds 
it hard to distinguish between probabilities like 0.13 and 
0.17, for example, since one does not have a intuitive feel- 
ing for many probabilities other than 0.5. In the next sec- 
tion, we demonstrate a method for obtaining the utility of 
consequences without requiring the direct assessment of 


probabilities. 


A technique for Utility Assessment 
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See Sesic concept is £6 assess the utilities of a few 
consequences and plot these on a graph with U(x) as the 
ordinate and x as the abscissa. We may arbitrarily assign 


utilities to two consequences for reference. Let us set 


u(xi) = 1 
and 
u(x0) = 0 


where x1 must be preferred to x0. (This normalization is 
equivalent to specifying the values of k1 and k2). Then we 
take the lottery in Figure 4.2 and find the value of x, call 
it x*.5, for which the decision maker is indifferent to the 
lottery. The utility assigned to x.5 must equal the 


expected utility of the lottery so 


Wie 5) — 9 0.5 U(x!) y+ 0.5 U(x0) = 6.5 


This gives us a third point on the utility graph in Figure 
oreo Our technique allows us to obtain the utility of a 
third consequence x.5 relative to the utilities of x1 and x0 
which were set to establish the origin and unit of measure 
ores w(x) . In obtaining x.5, we were able to keep all the 


probabilities encountered equal to 0.5. 
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The obvious question is "how does one get x.5?" This 
requires an interactive procedure, where the decision maker 
must state his preference between the specified lottery and 
a consequence. For instance, we would choose an amount xX. 
and ask whether the decision maker would prefer obtaining x, 
for certain or particiating in the lottery shown in Figure 
4.4. Regardless of which is preferred, we should be able to 
identify whether Xo should be increased or decreased to find 
the amount x.5 such that the decision maker is indifferent 
between it and the lottery. For example, it might be obvi- 
ous that x.5 > x,. Then when a second consequence x, 15 
compared to the lottery, we may learn x.5 > x. Such 1 ge ones 
mation will bound the true value of x.5. If one continues 


in the manner, the value of x.5 will be found. 


An Example 


Let us illustrate some of these ideas with an example. 
Suppose we wish to assess your utility for all monetary con- 
sequences between zero and one thousand dollars. You can 
think of these values aS possible changes in your net 
assets. Since you would probably agree that $1000 is pre- 
ferred to $0, we can arbitrarily set the origin and unit of 
U(x), where x is a particular change in assets, by U(0) = 0, 


U(1000) = 10. Our next step is to determine the amount of 
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assets for sure which you feel is the least amount for which 
you would agree to sell the lottery shown in Figure 4.5. 
That 18, we want your certainty monetary equivalent for this 
iMemiery . Suppose you decide it is $400. Then the utility 
which is assigned to $400 must equal the expected utility of 


the lottery, since they are indifferent and expected utility 


is our measure of preference. Hence, U(400) = 0.5 U(1000) + 
0.5 U(0) =5.0. We continue the assessment of your utility 
fume t10On. Let us attempt to find your certainty equivalent 


for the lottery shown in Figure 4.6. If this amount is 
$180, then the utility assigned to $180 must equal the 
eeapectea Utility of the lottery. So U(i80) = 0.5 U(400) + 
teow) = 2.5. Next we assess your certainty monetary 
equivalent (CME) for the lottery shown in Figure 4.7. Sup- 
pose your response is $650. We have: U(650) = 0.5 U(1000) 
pve oa U(400) = 7.5. The idea should be clear by now. Let 
us plot a graph of U(x). From the last five equations we 
hemes fave points on that @raph. The curve in Figure 4.8 as 
drawn through those points and represents your utility func- 
tion for any increase in net assets from 0 to 1000 dollars. 
From the curve, we can see, for example, that the utility of 
Cwi@mens SO. That is, U(700) = 8. Similarly U(500) = 6.3 and 


Be20O) = 3.0. 
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emer wchatacteristics of Utility Functions 


There are many curves which we could have drawn through 
the assessed Sone in Figure 4.8. For instance, we could 
have chosen to use linear segments to connect adjacent 
points, to use regression analysis to find the best fit 
quadratic curve, or to "wiggle" any curve with ups and downs 
through the given points. In this section, the problems of 


choosing appropriately shaped curves is addressed. 


Rather than just evaluate some points and smooth in a 
curve, it seems reasonable to first try to obtain the gener- 
eieeeomape §Of the utility function. This structure of the 


utility function can be specified by ascertaining whether or 


aeons the decison maker's preferences satisfy certain 
G@reerila. Each of these criteria putsS a restriction on the 
Bommeor the .wtility function. A useful technique is to 


determine the general shape of the decision maker's utility 
fiumetion by obtaining a qualita’ ive expression of his pref- 
erences, and then to choose a particular utility function 
Satisfying the general shape requirements which is also con- 


Sistent with a few carefully assessed values of U(x). 


The Art of Assessing Utility Functions 
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Assessing utility functions is perhaps more of an art 
than it is a science. The success one has in such attempts 
aS) closely linked with the analyst's ability to communicate 
with the decision maker -- to indicate the importance of 
this process, to enlist his support, and to make him feel 


comfortable with the assessment procedure. 


For discussion purposes, the assessment procedure might 


be divided into five steps: 


1. Preliminaries to actual assessment. 

2. Specifying the relevant qualitative characteristics. 
3. Specifying quantitative restrictions 

Mee nmoosing a utility function 


5. Checking for consistency. 


Ewe laminiaries to Actual Assessment 


Before beinning the assessment of a utility function, the 
concept of decision analysis should be discussed with the 
decision maker. Thus, he should realize the purpose in 
assessing his preferences and hopefully be sufficiently 
motivated to think hard about his feelings for the various 
consequences. It should be made clear to the decision maker 


that the preferences of interest are his -- that they repre- 
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Sent his subjective feelings -- and that there are no 
objectively correct preferences. At any time if the deci- 
sion maker feels uncomfortable with any of the information 
he has offered about his subjective feelings, it is perfect- 
ieee Fight -- in fact, necessary for the correct analysis 
-- for him to change his mind. This is one of the purposes 
of decision analysis, to require the decision maker to 
reflect on his preferences and hopefully straighten them out 


in his own mind. 


Specifying the Relevant Qualitative Characteristics 


The qualitative characteristics we are interested in are 
monotonicity and attitudes toward risk. To ascertain wheth- 
er a monotonicity condition 1S appropriate is quite simple. 
One asks the decision maker which 1s preferred between x1 
and x2, where x2 > xl. Probably you, the assessor, would 
expect a certain answer to the question based on your own 
understanding of the consequences. If x2 1s prefered, you 
would tend to think preferences are monotonically increasing 
in attribute x. You would then just ask whether more of the 


attribute is always preferred to less of it. 
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To check for risk properties, you might divide the range 
of the attribute as illustrated in Figure 4.9. We would ask 
the decision maker whether he prefers the lottery in Figure 
4,10 or its expected value Sh NI certain. Note that this 
lottery covers the complete range of the attribute for the 
problem at hand. If x. 1s preferred, we are inclined to 
think the decision maker is risk averse; if the lottery is 
preferred, he is likely risk prone. To check subranges, we 
ask for preference between the lottery in Figure 4.11 and 
its expected value, x,. We also ask the decision maker's 
preference between the lottery in Figure 4.12 and its 
expected value, Xo If the certain amounts are preferred 
here, as well as with the first lottery, we will probably 
find it reasonable to assume the decision maker is risk 


eaverse. 


If sometimes the lottery is preferred and sometimes the 
Sure consequence is preferred, we would need to check fur- 
ther to see whether the decision maker was risk prone in 
some region of x and risk averse in another, or whether he 


had made an error in his initial responses. 


Specifying Quantitative Restrictions 
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To specify quantitative restrictions, we perform the 
assessment of some points on the decison maker's utility 
curve. We have already shown how to do this by assessing 
the certainty equivalents of a few lotteries. There are a 
couple of pragmatic points to keep in mind, however. First, 
the consequences used in the questioning must be meaningful 
to the decision maker. Secondly, the spread of consequences 
in 0.5 - 0.5 lotteries must be large enough to be meaning- 
fully different. That is, 1f we are talking about a utility 
mumetaon for $0 to $si000, it 1s not very meaningful to ask 
questions about the certainty equivalent of a lottery such 
as the one shown in Figure 4.13 since there would be little 
perceived difference between the $500, $520 and the certain- 


ty equivalent. 


@moosing a Utility Function 


Once the qualitative characteristics have been specified, 
we will be able to select a parametric class of utility 
functions which satisfies these properties. Let us desig- 
nate this as U(x/A) where X} represents the parameters. We 
would expect at most three parameters to allow a suitable 


representation of any utility function. 
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Gvene iis x3 is the certainty equivalent for the lottery 
shown in Figure 4.14 we know U(x3/A) = 0.5 U(x1/A) = 0.5 
U(x2/A ) which gives us. one equation with the number of 
unknowns equal to the number of parameters. Using such cer- 
tainty equivalents, we obtain the same number of equations 
aS parameters, and then solve the set for the parameters. 


imesewill provide us with a utility function. 


Checking for Consistency 


There are many different consistency checks which can be 
used to detect "errors" in the decision maker's utility 
mine t1lon. By an error, we mean the utility function which 
we have assessed for him does not adequately represent his 
true preferences. There are a variety of ways to ascertain 
whether certain qualitative characteristics, such as risk 
version, hold for a particular utility function. One way 
can be used for a check on the results of another, etc. One 
generally useful check involves asking the decision maker 
his preference between any lottery and any consequence, or 
between two lotteries. In both cases, the expected utility 
of the preferred situation as calculated from his utility 
function must be greater in order to be consistent. Whenev- 


er the analyst feels uncomfortable about any aspect of the 
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Gecision maker's utility function, it would be useful to 


check this aspect and make any appropriate adjustments. 
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ONE, Sr MUI Sl IS UAE, SEB RTEINs 


Ships, like other large systems, have many attributes In 
General, the value of any design is seen to be some U(x1i, 
Mepeeawem), where xl 15 a Single attribute. Our next goal 
will be to assess and measure U(x), so that alternative 
design with different x, can be ranked analytically. This 
ranking should be somehow responsive to both the underlying 
attitudes toward varying amounts of each attribute and the 


relative importance of different attributes. 


When many attributes are considered in = wWhonce: 
evaluation, it 1s commonly assumed that: 


OGe = Oe U, [x (4) ] = De 
ZI 


alk 


madieess, Utility 1s additive and linear. 


In ee eular traditional benefit-cost analyses simply 
assign a constant dollar value (a, jal oer Uniteor caen 
non-monetary attribute, and then add up the resultant bene- 
ite Se. Individual preferences are summed up by converting 
all desires into a "willingness to pay” for a good or ser- 
vice, a process that in general favors the wishes of most 
well-to-do of the decision makers. The consequences of this 
fact are significant to the national naval budget process. 


os, 








The most interesting of cases of single-attribute utili- 
ty functions are distinctly non-linear, so the simplifi- 
eauzon  ©f UU, (x, ) to a; (x;) 1S not appropriate. Given 
non-linear utilities, however, it is then permissible to 


derive U(x) as 


U(x) = sy U(x,) 
i 


Certain sophisticated benefit-cost analyses, for example, 
Beesnmomtanear demand functions, and then add up the benefits 


derived from each attribute. 
However, consider the following example: 


x1 = endurance range 


x2 = maximum speed 


Obviously, the importance of each of these factors will 
not be independent of the other, at least to many observers. 
For example, the significance of maximum speed is very much 
damaged by endurance. Therefore, the difference between the 
utility of low speed and that of a very high speed is great- 
er if the endurance is higher. 
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wena LS shall, but 


Zz 


U 


U(0,b) 





when x. is large 


S15) 





Pememernat 4b > ha, which can mot be duplicated by an addi- 
tive model, in which oo > SGOMmearOULION FO Uti liey, 
may move up and down as x, changes, but,4,x,'s maximum con- 
MembwEron tO Utility, must be constant, regardless of the 
Wale Of x4. Note that U(x, ) is not depicted as being line- 


ar, either. 


Since we have discarded the linear and additive assump- 
tions for multi-attribute utility functions, you may wonder 
why we do not just estimate utility directly, as we did for 
Single-attribute utilities: choose the endpoints (U=0, U=1) 
use a 50/50 lottery to determine the utility midpoint 
items repeat to find the quartiles (U=.25, U=.75), and 
draw a smooth line through the points. In three questions, 
we determine five points on the utility function, and with 
some restrictions to ensure the curve is monotonic to assure 
@a smooth function, we can derive a reasonable approximation 


of the shape of that function. 





58 





However, when we attempt to extend this methodology to 
muiti-atttibute situations, we run into the famed Curse of 
Dimensionality. In two dimensions, we would presumable want 
Gowknow the utility of a0 least five points on each axis and 
their intersections in the planes: Now there are 25 points, 
Same nlc hmmOnlLy stwO are fixed by convention (U=0, U=1). If 
the determination of each point requires one question, 23 
questions are necessary to approximate the surface. Three 
attributes require 123 questions, four demand 623, and five 
necessitate 3123 questions. Decent results would be unlike- 
ly beyond 2 dimensions: even the most cooperative decision 
maker will be hard pressed to answer more than a hundred 
MOeEemyeagucSelons thoughtiully. Furthermore, under the pro- 
posed assessment technique, the maximum possible distance 
between a point of interest in the attribute space and the 
nearest point Roz which the utility has been assessed is 
proportional to the square root of the number of attributes: 
assessment becomes both more difficult and less accurate as 


dimensionality increases. 


Theoretically two approaches are possible to solve the 
Meset—attribute problem. As we demonstrated above, the 
first is an exhaustive comparison of alternatives; the larce 
number of assessments means this method has little or no 


practical merit. The second aporoach employs behavioral 
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assumptions tO approximate the exact utility function; the 
decision analyst uses these behavioral assumptions together 
with a few assessments to model the preferences 


analytically. 


This second approach is further divided into two schools 
Sr EnoOUGhe . The Harvard-MIT school restricts the Del iy 
function directly through "independence" assumptions about 
the preference between subsets of the attributes. The 
Stanford school separates the utility assessment process 
into two stages: Picnic wOLGeLING Of trade-offs Under 
ee einiy among the attributes and, second, the assessment 
of a risk preference function on one "numeraire", or rank 
order, for the deterministic ordering derived in the previ- 
ous stage. The basic research for that work is contained in 
the Ph.D tee es of D. Boyd and Thomas Green at Stanford. 
The remainder of this discussion provides an overview of the 


we 


Harvard-MIT approach. 


The Harvard-MIT method simplifies the problem but not as 
severely as the linear additive model first discussed. The 


utility function , however, is still decomposed: 


- 


BIS) aS oe [ey ox. Uj (%5), - + - 0%) 


— 
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eee rat ene ynGivicual U.{x.), each obtained by ask- 
ing 3 questions per rather than epproximating them with a 
linear function. Furthermore we will find some more sophis- 


ticated way of combining the U, (x, ) than simply adding them 


up. Specifically we will assume 


preferential independence 


utility independence 


Preferential independence is an ordinal quality 


the order of preferences (involving x, and x, 1s independ- 


ent of other attributes (x. eee fs x); Geucely stne Cnemee 


between two attributes is the same regardless of the level 

of other variables. Specifically, if one set of attribute 
; b 

levels ca ; 35 ) 18 preferred to another set x 


HE 
the other attributes have values (X., a xX) then (x5 


b 
1, Xo ) when 


b b 


; x5 Meee  pactersed to) x, x, ), even though the oth= 
er attributes take on different values co ; x -, aca Ce - 


jeeovmpolacally: 


a a 
(xt> XD) | Og. 1 Se 


(Xe a) Mes cnx). > (x? xP) iG oenrae ce 


ne 2 2 n ow 2 


Here is an example which illustrates the meaning of prefer- 


ence-independence: 
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GAse A Crore 


eee wOM eS PEED Cea eOorOorRT 
ReoeURCES NOT USED DS = OATS 1 RW SSE, 
MANEUVERABILITY IMPROVEMENT Dd. =v Sr eItON GEVEL 
Poneion TIME IMPROVEMENT oe = LIGHTING LEVEL 
PoONow@Or steel AVALLABLE b, = CROWDING INDEX 


IF WE KNOW 


EO O10'0 a" = 6,000 b. = 70db bo =) 60d. 
4 1 iu s AL 
103% ao = 20% b, = 10db be = 30db 

GIVEN THAT 
15% Db, pelea) 
500,000 b, = 53 

THEN GIVEN 
2s ae Se eng sla ieonelei(=q 
190.000 b = 27 such combination 


Peek NiCr wiNOmerNDENCE IMPLIES THAT 
Meow Ombs: TRHAT 


10,000 k a, 6,000 by = 70db , bo 
10% a. 20% bo = 10db Db. 


lI 
oa) 
© 
Ou 
‘oy 


lI 
UJ 
© 
A, 
oF 


The ordered pair is preferred 
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On the other hand, diet problems (among others) readily 


present counter examples to preference independence. 


While preferential independence does not hold in every 
case, i1t does show up in many practical situations. Even 
where it 1S not true of one statement of a problem, the 
problem can frequently be re-formulated in terms of vari- 


ables that are preferential independent. 


The second and much tougher assumption, utility independ- 
PulecmmepeGlmiecernat tie Shape Of U(x) as *. changes (with x, 
(izj) held constant) 1s independent of the level of the x. 
: With respect to design of a ship, for example, if the 


utility curve looks like: 


U 1.0 


> ?P D Jet Ole all 
Pier. 7 0 MAX 


then utility independence allows the function to look like: 





U 
Ay 
Ay 
OF { —— 
: P P P | 
PAIN PoRIT FO MAX MIN Chi 0 MAX 
PROFIT IE SLOLD IML 
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Mecaiety 15 poor, depending on U(Pmin, Safety Poor) and 
U(Pmax, Safety Poor): in each Eaceemaarr ort the utility 
Change takes place in the first third of the profit range. 


Emtec can not look like: 


Or 


Our U(Profit) can be expressed in a Single graph as: 





Once U~ and Uy, are determined (as a function of safety), 
the utility curve for profit is fully defined. I£ we know 
the utility of some amount of profit P,, given safety level 
1, what does that tell us about U(P,), Given safety level 2? 
Cur sucrlity andependence assumption requires that U(P,5), 
always be some fixed proportion of ope ays ances rr on Ua co ux 


soe 


64 





Therefore, 
U(P,S) - Un (S) 
———_—__—_——————— = Constant 
uU~(S) - U4(S) 


Semueeraing S = 1 and S = 2, 


U(P 1) - Uy(L) » (UX(2) - Uy(2) 
U(P, 2) St Uy, (2) 
U*(1) - U,(2) 


Or 
U(P, »2) = Oa 2 bso 2 ERE ae by 5 wu (Pd) 
where 
wo 
ee Om 
i wo 
UG) 2 oe 
One 
Wee 2} Shy a be a U(P, ,1) 
where | 
ai = la) DL > ae (1) 
Now ag and by > are only functions of safety so, 
U(P 2) = a5 + boo . U(E, 2) 
Therefore, 
U(P, 2) = ais + b, 3 U(P,1) 
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mom all ©, 


Pauetion (A) 


fembaty ("shape") 
between lotteries 


Mevel Of Other attributes. 


For example, given: 
B 
Pp 
A ~~ — 
l=p C 
we know 
U(A,1) = p°U (B,1) 
fo show that 
Zee POUNCE 2) es 


Eaat 1S, 


the indifference between 


RiGee 2 near EbPensrtormarion, of U(P,1). 


allows us to prove a very important point: 
independence implies that preference 


in one attribute is not affected by the 


Profits Ore 


Safety = 


De Be 
0 


sp Ee) Ge) 


(1-p) 21) VOR) 


A and the lottery 1S main- 


tained when safety changes, we simply note (dropping the 


elasCripts) : 


U(A,2) = 


pe (82) 


(1=-p) small) (Gy 2s 


Bee SUA, |) Salo (1-p)] +bf[p -U(B,1)+(1-p)-U(C,1)] 


p[atb- U(B,1 J+ (l-p)[a + b- U(C,1] 


And that's why it's called utility independence! 
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We have discussed preferential independence two attri- 
butes with respect to all other attributes, and utility 
independence of one attribute with respect to all others. 
The independence concepts can also be defined in terms of 
other numbers of attributes -- but such properties need not 
be demonstrated in order for the following technique to be 


justified. 


67 








Artificial Intelligence 


The second technique offered will be called broadly 
termed artificial intelligence. Plenougneat 1S certainly 
true that a computer can not think, it is foolish to over- 
look or ignore the computer's ability to recall out the 
actions, good and poor, taken by others. In simplest terms 
decision maker acts, not only on his own opinions, but upon 
the preceived or known actions of thers in similar circum- 
Stances. The field of "artificial intelligence" is little 
more, in this least sophisticated form, than pathed actions 
made by the computer based on a statistical preference of 
“previous human decision makers. Although this research will 
not attempt to develop the scientific basis for artificial 
intelligence aided decision making, it will stress one opin- 


HON. 


To use this discipline a foundation of previous decisions 
in similar circumstances is required. Since individual lev- 
el decisions are being made in existing combat simulation 
and ship synthesis models, the retention and cataloging of 


them should be started. 


It is believed that both utility theory and artificial 
intelligence might prove significant aids to our unresolved, 
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but pivotal problem. The ultimate decision of which 
Guanitates and in what proportions should be included in a 
Specific design. The purpose of each is the same. Show the 
decision maker how to include his preferences within a deci- 
Slon toward a consistently defined problem. It is this need 
for a common definition of the problem which must be solved. 
It is offered that we have multi attribute utility theory to 
address the number of elements and, perhaps, artificial 
intelligence to assist in the problem of multi decision mak- 
ers. The two techniques may prove ultimately complementary 
to the resolution of the appropriate ship design objective 


Bunecion. 
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CHAPTER 5 


THE ASSES SHiP SYNTHESIS MODEL 


A method must be found to translate the hardware payload 
and the conceptual platform into first, comparable terms and 
second, into a first approximation of a ship. In this 
project the following characteristics for this translation 


were considered desirable. 


1. Executable within DEX software. 
2. State of the art model 
3. Interactive 


4. Able to take full advantage of this models the 
framework of the model we have proposed. 


The most efficient method of achieving the second of 
these objectives was to find an existing ship synthesis mod- 
el which was developed to to incorporate many if not all, of 
the aspects we identified in previous chapters as essential. 
with the limitations of other models discussed in chapter 1. 
Independently to this research, the project team was intro- 
duced to the directors research team at the David Taylor 
Model Basin in Carderock, Md. This group was actively 
involved in the development of a ship synthesis model 
intended to provide for the analysis of the effect of tech- 
nological changes upon ae ship design at the feasibility 
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Stage of the design process. The "Carderock" model is 
excellent for the purposes of our effort. This is because 
it can be initiated by the fewest and most elementary of 
descriptive parameters. In addition the Carderock model 
allows for development/modification of all included concepts 
in extenSive depth. Because of the significant efficiencies 
to be gained by uSing an existing model in our project, and 
DEXs' ability to accomodate existing analysis code with min- 
imum modification it was decided to develop the combat 
effectiveness model with the explicit intention of using 


ASSET as the vessel synthesis technique. 


The Carderock model is called Advanced Surface Ship Eval- 
uation Tool (ASSET) and is an interactive computer program 
for use in preliminary evaluation of frigate, destroyer, and 
crulser-type ships. It will ultimately encompass virtually 
all major technologies that are relevant to the design of 
such ships, including hullform sizing, hydrodynamics, pro- 
pulsion, structures, weights, hydrostatics, cost, manning, 
Space requirements and survivability. The program features 
design synthesis capability, options, including interactive 
gQraphics and use of either English or metric units. ASSET 
is primarily intended as an interactive tool for providing 


timely resuts to engineering queries. 
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ASSET was designed to avoid the pitfalls typical of pro- 
grams of similar scope, such as extreme difficulty of use, 
poor responsiveness to engineering queries, and inadequate 
technical depth in the multidisplined environment. The 
ASSET engineering modules for ship design are manipulated by 
the user via a small yet powerful set of commands. ASSET 
was designed to execute interactively via a teleterminal to 
provide desk-top convenience while avoiding delays inherient 
in batch (card) oriented systems. Finally, the ASSET engi- 
neering tools represent most of the major technologies that 
are relevant to destroyer-type ships. ASSET consequently 
allows an increase in engineering productivity during the 
Ship design cycle by allowing the user to apply the ASSET 
engineering tools in an easily-used, responsive, yet techni- 


cally sophisticated environment. 


Use of the ASSET engineering system closely parallels the 
classical process of ship deSign. The design team begins 
with a set of mission requirements that the proposed ship is 
to accomplish. Existing design data and computational pro- 
cedures are employed in an iterative sequence to derive a 
ship design, as exemplified by the design spiral. ASSET's 
value is in the automation of many of the manual processes 
performed in the iterative design process. Instead of manu- 
al search through lengthy residuary resistance coefficients, 
ASSET performs the search. Instead of manual construction 
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of a plot of hydrostatic righting are versus heel angle, 
ASSET draws the plot. Instead of manual storage of design 
data in notebooks, ASSET stores the data on computer disk 


files, from where it may be easily recalled and reviewed. 


Although many of the precesses involved in the design of 
a ship are automated by ASSET, the program leaves the crit- 
ical engineering decisions to the designer. ASSET makes no 
attempt to decide whether to employ waterjet or propeller 
propulsion, whether to use Newton-Radar or Wageningen-B 
propeller curves, or whether to use a three or four bladed 
propeller. ASSET makes no significant design decisions 
whatsoever. The program employs selected algorithms to per- 
form selected calculations. The designer retains essential 


control of the program. 
PROGRAM STRUCTURE 


PROGRAM CONCEPTUAL ORGANIZATION The system is composed 
of five principle elements: the designer, an executive pro- 
gram, a series of computational programs, a ship design 
undergoing generation or analysis (called "current model"), 


and a data bank. 


DESIGNER The designer is the controlling element of the 
ASSET system. Through a simply command language, the 
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designer directs execution of, or interaction between, the 
remaining system elements. Although capable of batch (via 
cards) execution, the ASSET system was designed as an inter- 
active tool for ship engineering. Consequently, the design- 
er typically utilizes ASSET by means of a teleterminal where 
commands may be entered and results of those commands imme- 


diately reviewed. Delays are thereby minimized. 


EXECUTIVE PROGRAM The executive program is the ASSET 
system element that interprets each user command and there- 
after performs each task that is required to accomplish the 
user instructions. The executive program is also the lone 
system element that can directly interact with each of the 
other system elements. Performance of any given user com- 


mand generally involves the remaining three system elements. 


CURRENT MODEL The current model element of the ASSET 
System is the temporal collection of data that represents 
the one ship design under generation or undergoing analysis. 
All program computations use current model data only. The 
current model is temporal because it exists only during exe- 
cution of the program. To become permanent, current model 


data must be transferred to a permanent Storage device. 


DATA BANK A data bank has been incorporated as an ele- 
ment of the ASSET system for the purpose of permanent 
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retention of ship data. Entire current models or pieces of 
a mrrent model may be stored in the data bank under a name 
selectable by the user. During an ASSET session, ship data 
may be transfered from the data bank to the current model or 


meom the current model to the data bank. 


The executive program, the current model, and the data 
bank can also be employed to create entirely new ships in 
the current model by recall from the data bank of pieces of 
data from different ships. For example, one can transfer 
Ship data corresponding to the propulsion system of Ship A 
from the data bank to the current model and then transfer 
hull offset for Ship B from the data bank to the current 
model. The current model would thereby contain a vessel of 


Ship A type propulsion system but Ship B type hull. 


COMPUTATIONAL PROGRAMS 


The calculative function of ASSET list performed by the 
element that consists of eleven computational programs. 
Each program represents a distinct engineering technology 
that can be applied to the design and analysis of ships. 
Through a simple command to the executive program, it is 
given to the computational program. Following termination 
of the computational program, output data, selectable by 
menu, are displayed to the designer. Certain computational 
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programs also add to, or modify, the current model as part 


of the ship design-generation process. 


COMPUTATIONAL PROGRAM TYPES Three types of computa- 
tional programs within ASSET: initialization, synthesis, 
and analysis. The description of the programs within each 


type is given below. 


The initialization section of ASSET consists of a single 
program. It utilizes simple empirical methods to calculate 
a variety of ship data. As 1ts name implies, a primary 
function of the initialization program 1S to provide an ini- 
tial starting point for a new design under development with 
Book. . A secondary use of the initialization program is in 


performance of high-level, parametric trade-off studies. 


Six synthesis-type computational programs exist within 
ASSET. Each program is concerned with a single technolog- 
ical area of the ship design. In contrast to the initial- 
ization program, each synthesis program utilizes rigorous 


analytical techniques in computation of ship data. 


The third type of computational program is called analy- 
Sis, of which there are four. Like the synthesis programs, 
rigourous analytical techniques are employed. The principal 
difference between synthesis programs and analysis programs 


va°) 








is that synthesis programs modify the current model. Analy- 
Sis programs do not modify the current model, only provide 
additional information about it. Also unlike analysis pro- 
grams, synthesis programs can be employed in an iterative 
loop to converge ona ship design. The process, known as 
design synthesis, is simply an automated traverse of a 
design spiral from the mission requirements to the converged 


upon ship design. 


COMPUTATIONAL PROGRAM FUNCTIONAL DESCRIPTIONS 


The function performed by each ASSET computational pro- 


Gram is described in the following section. 


INITIALI ZATION 


This program is normally the first program to be exer- 
cised after assembling a new ship in the current model. 
Data is thoroughly checked for completeness and if no fatal 
errors exist within the data, a mini-design synthesis proc- 
ess is initiated that contains geometric, hydrodynamic, pro- 
pulsion, performance, and weight calculation capability. 
Simple empirical methods are used throughout. The calcu- 


lation sequence used by this program is as follows: 


ie, 








1. Input data are checked. 

2. Ship weight is estimated. 

3. Hull is resized, if requested. 

4. Auxiliary and electrical systems are sized. 

Seeenuliborne ship drag force is calculated. 

6. Hullborne propulsion system is sized. 

7. Ship range or fuel weight is calculated 

8. Ship weight is recalculated. 

9. If the ship weight calculated in step 8 does not equal 
the weight as previously calculated, the mini-synthesis 


cycle 1S repeated from step 3 until weight convergence 
Securs. 


HULL GEOMETRY 


The hull geometry program defines girder, and deck 
locations, and also defines superstructure yas. T Jk Bul TL 
geometry. Hull offsets in the current model are scaled and 
warped to define a new fullform that meets requested phys- 
ical characteristics. This program includes portions of the 


Navy program “Hullform Derived from Parent." 


Mieceemodile caleulates Scantling data for the ship ele- 
ments defined in the current model. The calculations are 
based on pressure loading data which are either calculated 


by the program or input by the designer. Scantlings are 
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determined at three longitudinal locations for the hull bot- 
tom, hull sides, and weather deck. Additional scantling 
data are calculated for lower decks, bulkheads, frames, 


girders, beams, and stiffeners. 


HULLBORNE HYDRODYNAMICS 


The hullborne hydrodynamics program calculates ship drag 
during hullborne operation. Either planing hull or Taylor 


Standard Series drag-type calculations may be performed. 


HULLBORNE PROPULSION 


The module performs s1iZing calculations for either a 
waterjet or propeller propulsion system. The 
waterjet-propulsion system section of this program calcu- 
lates engine power requirements, water-duct losses, pump 
size, and operating data based on given drag, duct, and pump 
type data. The propeller size, and propeller operating data 
based on given drag, gearbox, and propeller characteristic 


data. 


FUEL /RANGE 


Range performance is calculated by this program in either 


of two ways. The weight of fuel required to achieve a spec- 


ike, 





ified hullborne range is calculated or the range which may 
be achieved by a given ship is calculated. The calculation 
mode iS Specified by the designer. Fuel requirements for 


auxiliary and electric plants are also considered. 


WEIGHT 


The weight program calculates a detailed weight breakdown 
mor the ship. The weight statement follows the Navy Ship 
Work Breakdown Structure, SWBS.(see OPNAV Inst 9100.2b, 
978 ) | 


PERFORMANCE 


The performance program calculates the performance char- 
acteristics of ship designs that have been generated via the 
design synthesis process. Whereas design-synthesis perform- 
ance calculations assume calm water and a clean ship, the 
performance program considers fouling effects of marine 
organisms, degradation of machinery with time, and sea state 


operation. 
COST 
The cost program estimates ship costs for the purpose of 


design tradeoffs and comparative evaluation. Both unit pro- 
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duction costs “and life cycle costs are addressed. Simple 
empirical relationships based primarily on the Navy SWBS are 
used to estimate unit costs. Life cycle costs are estimated 


utilizing a variety of data. 
GEOMETRY DISPLAY 


The geometry module produces plots of ship geometry. 
Hull lines, bulkheads, decks, and superstructure can quickly 


and eaSily be assessed for correctness by the designer. 
DESUGN -oYNTHESIS 


The design synthesis process is another step employed in 
the manual process of ship design that has been incorporated 
into ASSET. After establishment of mission requirements, 
the designer typically generates an initial design to serve 
as a starting point. This initial design may be a previous- 
ly established design of similar function or an entirely new 
concept. Unfortunately, the initial design is seldom satis- 
factory. Minor or gross modifications must be performed. 
For example, additional cargo volume may be needed. The 
designer may elect to expand the hullform to satisfy this 
need. But expanding the hullform changes ship resistance, 
which impacts required propulsive power, which may demand a 
new power plant, which may change the amount of fuel carried 
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to achieve a desired range. The modified hull, propulsion 
plant, and available fuel impact the total weight of the 
ship. The initial estimate of ship displacement for which 
resistance calculations were previously performed may 
require revision, and new resistance calculations may need 
to be performed. The design spiral goes on and on, hopeful- 


ly toward a converged design. 


The key to operation of the design synthesis process is 
the ability of each synthesis module to modify the current 
model. Critical ship data in the cuerrent model such as 
hull lines, superstructure characteristics, hullborne drag, 
hullborne propulsion data, fuel/range data, and ship weights 
are modified during the synthesis process, each by the 
appropriate computational program. Convergence of a ship 
design occurs when two passes through the synthesis loop 


produce virtually indentical designs. 


This project has been designed to implement ASSET through 
the techniques of the DEX. Initial investigation with the 
ASSET development team has confirmed the opinion of the team 
that initiation of ASSET through DEX will be relatively 
Straightforward. It iS expected that the initialization 
section of ASSET can be called into this model, through DEX, 
in as few as 4 menus consisting of approximately 15-20 
design parameters. 
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CHAPTER 6 


COMBAT EFFECTIVENESS 


This section is the most important of the entire project. 
The development of this section focused upon the following 
three considerations. 

Completeness 
Accountability 


Applicability 


Completeness 


The content of this section is as follows: A. the situ- 
Mevenmmets Gertined, including; the composition of forces on 
both sides (this information is obtained from the current or 
a redefined situation obtained from section ia "Threats and 
Environment" 8B. The operation or employment of each vessel 
is specified. In this sub section, the opposing forces are 
further defined as modeled at the moment at which an esti- 
mate of combat effectiveness is desired. The sub section 
will prompt the user to specify the status of each major 
parameter of the opposing forces. It 1s intended that this 
potentially laborious task be eased by having this specifi- 
cation done by default. That 1s, that items not 
high-lighted by the user are assumed to be operational and 


in operation to the extent of availability and performance 
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previously given. C. The definition of combat effectiveness 
is assumed to be an unspecified combination of the amount of 
"damage" inflicted upon the enemy and the amount of surviv- 
ing capabilities of the designed vessel after the action. 
Bach of these major combat effectiveness parameter paths is 
developed to the degree required by the other two consider- 
ations of this section; accountability and applicability. 
Note that we are, again, avoiding answering how much each of 
these paths might contribute to an overall definition of 
"effectiveness". Extensive amount of discussion with opera- 
tional and design authorities indicated that such an 
evaluation is a function of 
How the totality of overall conflict is perceived 


The perceived strength of enemy in general area (poten- 
tial immediate opponets) 


Perceived relative strength trends of the opposing 
forces. 
Accountability 

In various areas of this model, extensive menu strings are 
taken, intact, from one section to be used in a higher level 
section. As such, these strings must be correct and concise 
as possible for all sections in which they are used. They 
should provide the difficult balance between what is neces- 
Sary to sufficiently specify the problem, and the desire to 
limit the total number of possible decision points to sim- 


plify the execution of the model. The method used to 


84 





accomplish this trade-off was "comparision and reduction" 
from a higher (earlier) section to the section under devel- 
opment. For example, in choosing the surviving capabilities 
to be included in the "Combat Effectiveness" section (7), 
the section describing the payload (3) and the section list- 
ing the platform characteristics (5) were compared. From 
the gross list formed by the total of the two sections, a 
shorter list was formed by eliminating redundant or overlap- 
ping elements. As discussed in chapter 2, this reduction 
was accomplished by weighing the opinions of several 
War-gar.ng experts (most notably, John Corsey of the U §S 
Naval War College) and personal opinions gained by the 
author from specific literature reviews (see the bibliogra- 


phy section on "Professional Publications"). 


As might be concluded, this is a highly subjective proc- 
ess with all the attendant dangers of such a generally 
described process. Because of this, the validity and com- 
pleteness of this section should be the initial area con- 
firmed by any future researcher in this field. Within this 
Section, the output or product of the entire project is the 
most sensitive to changes in format and construction of the 
individually included menu items. To aid in menu account- 
ability, a section menu to section menu listing for the 


Section is given below. 
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COMBAT EFFECTIVENESS MENU 


THREAT MENU 


must be consistant with 


"threats neutralized” 


(by type) 


"threats damaged" 


(by type/amount /area ) 


COMBAT EFFECTIVENESS MENU 


must be consistant 


"self defense capabilities" 


"force defense capabilities" 


"offensive threat 


neutralization capabilities 


COMBAT EFFECTIVENESS 


"threat type” 


"threat types" 


PAYLOAD MENU 


with 


"Dayload; self-defense" 


"pDayload; force/area defense" 


"payload; offensive threat 


neutralization capabilities" 


PLATFORM CHARACTERISTICS 


must be consistant with 


"flag CCC capabilities" 
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Applicability 


This term is used to indicate the constant responsibility 
for each included menu item to be necessary. There is a 
conflict with this desire and the stated "design philosophy" 
precept concerning highest level development. Because of 
the desire to give precedence to the design philosophy, 
there was been only first order efforts in the area of 
applicability in the model as a whole. In the Combat Effec- 
tiveness section the availability of experts and excellent 
references, allowed some significant "winnowing"” of the Sec- 
EaON . In general, this section is designed around the 
existing gaming algorithms as used in this country. Many 
elements which would be significant to the naval architect 
are not significant to the combat simulator because he sim- 


ply has no way to account for them. 
Operation of the Combat Effectiveness Section 


Once the uSer has defined the general situation from 
which he wishes to obtain an estimate of combat effective- 
ness, he is ready to exercise the sections computational 
areas. Because this area is designed to be the most innova- 
tive of the project, we will describe this translation. The 


Sequence would proceed as follows: 
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DETECTION RANGE CALCULATION 


Char nve TeCunN toon 


(MAXIMUM SENSOR RANGE 30 nm) 
TYPE 1 









PROBABILITY OF DETECTION 


Onm lOnm 30nm 
DISTANGE IN nm 


DETECTION RANGE THRESHOLD (67%) = 10 nm 





PEGURE CE = 





ie The setting of the conflict is established. As previ- 
ously discussed, this might include, weather, other 
units or any other factor which could affect the outcome 
of the engagement as modeled. 

a The operating status of the units is defined. Here we 
Specify the on/off status of the sensors, weapons or 
other equipments having a detectable signature. 

B. The relative position of the conflicting forces is set. 
There are several range possibilities, with attendant 
action possibilities including; 

Outside of sensor range (by sensor system) 


Inside sensor range, outside all weapons systems 
ranges 


Inside sensor range, inside weapon systems range ( 
by weapons system) 


Inside minimum weapons range (by weapons system) 


4, Action is joined at the range specified in step 3 


Once either unit is within the maximum dectection range 
of an operational sensor, the detection event must be 
resolved. The detection event can be looked at in two ways. 
The probability of detection at a given range, or the range 
Bimeaemciven probability of detection. Since we need the 
range of an action to proceed to the next step in the model 
we will use the range at which the target is assumed to be 
detected by the sensor. The method used to find that range 
could take many forms. The most accurate might use histor- 
ical information from "Similar" encounters. Another 
technique would be to use the design specifications of the 


equipment. The third method might be algorithimic. This is 
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the technique we will use. In this algorithim, we will 
assume a linear "curve" describing the distribution of the 
probability of detection from the maximum design detection 
range to the minimum. See figure CE 1. This implies that 
the target 1s becoming more easily detected as an inverse, 
linear function of range. In addition, we will specify 
that, not withstanding the finite probability of a detection 
at any range less than system maximum, the target will be 
assumed detected only when the probability of detection 
reaches 67%. That 1s, in 67% of assumed cases the target 
was detected prior to this range. In the example on the 
next page, dectection will, therefore, always occur at 10nm. 
This assumption is not as artificial as it might appear, as 
most systems and systems operators do not, routinely, per- 
form to the systems Tag wmewleoal” Specifications. The actual 
percentage threshold range 1s arbitrary, of course. 
Although a more generous threshold detection range may be 
specified, it is not important to the technique. An example 


is developed in figure CE 1 in graphic form. 


Given that the detection has occured, the next opera- 
tional decision would be to join or decline action. If, in 
the model, the defined situation, (or the users override, 
see chapter3 page 30) specifies action the model proceeds as 
follows. 

Weapons Action 
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A weapons action is defined as the determination of the 
number of expected hits by a given weapon upon a given tar- 
get at a specified range. The calculation assumes that the 
system is operational and the target is within maximum weap- 
ons range. Of the many possible methods of such a determi- 
nation, this model will; 1. Define the length of the 
engagement. This will give the number of rounds fired based 
upon the systems firing rate (note that firing rates are not 
necessarily single valued). In our example, 1 minute firing 
with a firing rate of 30 rounds per minute gives 30 rounds 
fired, 2% Calculate the weapons Pelreular error 
probability" (CEP). This parameter meaSures the expected 
dispersion of warhead impact points as a function of range. 
In simple terms it describes the circle within which 50% of 
the rounds fired would be expected to land. BOnsouL 
example, we will use a simplified but representative 
algothrim, much like the sensor detection format. In our 
example, the input range of 10 nm, from sensor detection 
range is within the maximum weapons range of 20 nm and the 
model "opens fire". From the CEP curve , figure CE 2, the 
initial CEP is 500 yards. Therefore if the opponets main- 
tain 10 nm separation, it may be expected that 50% of the 30 
rounds fired, or 1i5 rounds, land within 500 yards of the aim 
point or target. Again we simplify by assuming perfect aim, 


but inclusion of an aim error would be a straightforward but 
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forgone matter. The next problem is the assessment of the 


effect of the hits (if any) upon the target; the damage 


assessment. 


Damage Assessment 


There are, again many .methods of assessing possible dam- 
age inflicted upon a given target by a specific pattern of 
rounds. This model will use a percentage coverage approach. 
In this approach, the percentage of the CEP covered by the 
target (the length of the target divided by the CEP) will be’ 
multiplied by the number of rounds landing (randomly) in the 
CEP (up to a maximum of one). This gives the expected num- 
ber of rounds landing upon the target. In normal practice, 
any one of several scientific techniques are used to make 
this number an integer. In the case of the model, we would 
use a random number generator with even or odds last digits 
determining round added or subtracted from the integer, 
respectively. In our example, we will assume a target 
length of 300 feet (100 yards). Our target "fills" 100/500 
or 0.20 of the weapons dispersion (CEP) so that 0.20 times 
15 rounds or 3 rounds are assumed to impact the target. 
Although the amount of damage inflicted by a single round is 
not independent of the impact point along the ships length, 
Since the weapon dispersion is random, we will not address 
any difference in types of "hits". Therefore assuming a 
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random distribution of hits, random normal is acceptable, 
the type and effect of the damage might be determined by the 
model from a table or curve such as figure CE 3. Again the 
Gomme OL this curve is critical-to the outcome of the con- 
flict, but not important to the development or execution of 
the model. Damage curves, such as figure CE 3, exist in 
Several places where combat simulation has been conducted 


for decades. 


From our example damage assessment curve of figure CE 3, 
it is assessed that the 3 hits inflicted upon our target 
force it to retire. The implication is that the opponet is 
out of action for a period of time, but may return to action 
after some repairs. This type assessment (Sunk, retire, 
etc) as results of specific damage accumulations, is very 
Subjective but absolutely essential. [ie 7 ay alinvetoveteryniv 
because it affects the operation of the opponet and thereby 
affect the actions and performance of both sides. This 
determination of elimination, temporary removal or degrada- 
tion of a unit is required to permit the model to conduct 


multi-unit assessments. 


To recap our example Our ship (P) detected opponet (K) at 
10 nm by sensor A. We engaged ship K at that range with 
weapons system B. In 1 minute of firing, we inflicted 3 
hits, forcing our opponet to retire. 


a2 





This iS interesting, but what was.ship K doing to us in 
the meantime. The answer is , exactly the same sorts of 
things we were doing to him. Obviously, certain actions by 
one opponet would be precluded from execution by the outcome 
of actions by the other. For example, if we suffered enough 
damage to be sunk before the 1 minute of firing was con- 
ducted, we could not have forced our opponet to retire. 
This brings up the problem of time versus event modeling. 
In the simple cases we will describe in this model each con- 
flict is being treated as a separate event. A more accurate 
depiction would permit the proportional sequencing of events 
to form a multi-state assessment. For the present, this 
model must address each change to the combat situation as a 


Separate entity. 


Measure of Effectiveness 


In our example, ship P forces ship K to retire (turn 
back) with 50% damage to its systems. In turn, ship P suf- 
fered uncalculated damage in that same event. To state how 
effective P was against K, we must weigh the relative value 
of the two damage states of the opponets, and the actions 
expected to result from that damage. Thus our measure of 
effectiveness is the desired balance between the two differ- 
ent "combat effectiveness" menu branches of; A Surviving 
Capabilities (starting at menu page ) and B. Threats 
neutralized (starting at menu page ). This balance 
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must be established by the designer or user of the model. 
Most likely, a comparision of the different results of a 
number of opponets and in a number of different situations 
will be necessary. Methods of obtaining such a blending of 
seemingly conflicting outputs are offered in chapter 4. One 
additional note; even this extremely simple action sequence 
shows the advantage of internally consistant computer man- 


aged data bases over more conventional approaches. 
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CHAPTER 7 


COMBAT SIMULATION 


In this chapter we will trace an example of the combat 


Simulation section module. We will simplify the case by the 


following assumptions: 


Both forces fully defined 
Single unit interaction 
Minimum additional external factors (weather, jamming) 


Fully operational units 


We have chosen, aS our opponents, the FFG-7 frigate 


class of the U.S. navy as it might be expected to be config- 


ured today, and the Krivak II frigate of the Soviet navy. 


This choice, as made provides 


Approximate equality of 


size 

manning 

Speed 

relative positon in “order of battle"; that is the rela- 


tive importance of the ship class in the countrys’ total 
naval force. 
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These ships are designed for different primary warfare 
missions (FFG-7 = AAW, Krivak = ASW). The baseline units 
and situation is described in table CS-1. We will demon- 


Strate the modules capabilities by explaining its ability to 


ee Model the revelent parameters of the specific situation 
2, Be sensitive to changes in unit configuration opera- 


mronal Senarioc. 


Four alternative sets of combat effectiveness values will 


be attempted 


Hie Baseline/no harpoon missiles on FFG-7 
2% Baseline/harpoon on FFG-7 
S. Baseline/units at 35 nm initial range 


4. Baseline/Units at 5 nm initial range 


The model would retrieve the baseline Krivak and FFG-7 
(Perry) from the threat (section 1A menu ), and (sec- 
tion 5 menu ), respectively. See table CEi for high- 
Eights . Thus there, will be four cases: Harpoon/3s5nm, No 
harpoon/35nm, Harpoon/Snm, and No harpoon/Snm. In all cases 
the units will be initially unaware of the adversaries pres- 
ence. They will, therefore, be employing an 


acoustic/electronic emission control scheme design intended 
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to optimize the respective units primary warfare mission 


area. Table CE-2 shows these conditions. 
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lst CASE (No harpoon/35nm) 


In the initial circumstance we will assume, due to the 
range and partial emissions control posture, of both 
vessels, that neither ship "knows" that the other is in the 
immediate area. Thus, our Situation would start with a 


detection of either unit by the other. 


1. Sensor performance (detection). 


Examining the two opponents sensors versus the appropri- 


ate signature levels, we might conclude the following: 


Air detection - none 

Surface (radar) detection - none 

Electromagnetic detection - potential soviet ECM vs 
SPS-55 & SPS-49: potential US ECM vs DON-2 (less than 
above) 


Acoustic detection - potential TACTAS vs soviet VDS; 
potential TACTAS vs soviet propulsion 


DOMINANT PROBABILITY 


1st assumed detection: TACTAS (convergence zone) on 
Roivak. I! at 28nm. (see chapter for assumed sensor per- 
formance algorithm: use max range of 90nm (2nd CZ)) Since 
no weapons are assumed to have range to exploit this 
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detection, Situation continues until range closes to less 
than i5nm at which time FFG-7 launches standard missle in 
active/ARM (anti radiation missle) mode on Helo (lamps) sol- 
ution - note that FFG-7 class would/should attempt to main- 
tain maximum standoff if possible. Also note that TACTAS is 
not assumed to provide a fire control solution. The possi- 
ble firing doctrine might call for a single shot with ready 
second round fired upon damage assessment or unacceptable 
first weapons telemetry data. In this situation we are 
going to assume a hit based upon a positive random probabil- 
ity less than 1.0 and an out of action status to the Krivak 
with 40% total systems degradation. No damage or missions 


interference is assessed to the FFG-7. 
Considerations 


If the FFG-7 is not ARM configured and if LAMPS is not 
able/allowed to provide fire control solution or weapons 
delivery (not discussed), the situation, would most likely 
deteriorate to a gun fight. This assumed that the sometimes 
accredited anti-surface capability of the SSN-14 is inaccu- 
rate. In short, the margins of the weapons systems 
Capabilities totally dominate our solution and must be 
defined/specified/agreed upon to validate to outcome or 


specify the solution. 
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CASE 2 Harpoon/ 35nm 


Same as Case i in initial aspects up to the weapons 
action (each side has the same sensors as case 1). Note, 
however, that probablistic models of detection or weapons 
performance might very well give a different function to the 
beginning of the problem). If, however, the situation is 
considerated constant, the following trends in performance 


might be expected: 


LAMPS cease needed TOF “Over the horizon fire ContEroL 


SolUtL ION 


Harpoon missile deployable at opening (from initial 


detection range) target up to 55nm 


Lethality of harpoon much better than standard missile 


This model would more often assess a sunk Krivak, with all 


that event might imply to other actions. 


Outcome assessed 


Sunk Krivak, Undamaged FFG-7 
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Considerations: 
The possibility of damage to FFG-7 is much lower in this 
case that case 1. Thus it iS a much better situation than 


Case i for FFG-7 although assumed outcomes might be consid- 


ered "equal". 
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CASE, 3° No Harpoon / sam 


In this instance it is assumed that the two units are 
together (that formal hostilities have not started) In this 
Situation detection 1s assumed and valid fire control sol- 
utions are assumed to take equal amounts of time for both 
vessels. Even if the Krivak does not begin/or have a fire 
control solution before the FFG-7 the only appropriate weap- 
ons on both ships are the guns. Given the number /rate of 
fire/size of shell of the soviet guns over the U.S. gun the 
model would generate 3 hits in 20 seconds of firing (see 
example weapons system performance, Chapter with range of 
Snm and 8+nm) on the FFG-7, while the FFG-7 inflicted only i 
hit upon the Krivak. Using damage assessment curves we 
megne conclude outcome: FFG-7 out of pewior - 70% systems 
degradation. Krivak damaged - 10-15% systems degradation, no 


change in operations 
Considerations: 
If LAMPS not airborne, damage potential to FFG-7 much 


higher. there is avery high potential advantage to unit 


initiating action due to in contact status of both units. 


al 81% 





CASE 4 Harpoon/ 5nm 


The existance of harpoon does not change the outcome from 


Seo III. 


Outcome: Same as CASE 3 FFG-7 - out of action; Krivak 


- continues mission 
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Discussion 


The operation of this example points out two major con- 


tributions of this project to the naval ship design process. 


It provides a systematic method of providing consistant 
input to either an existing war gaming model or a model 
internal to this project. This is an essential element 
for naval ship design assessment. DEX provides extreme 


flexibility in this matter. 


This project permits the essential communication between 
the various design levels. In deriving our objective 
function (combat effectiveness), we have attempted to 
use the parameters important to each significan disci- 
pline involved in the naval ship design process. This 
should permit the participants to communicate, in common 
terms, with one another. In short, we have provide a 
common language (the model) to address the same question 


(What is the designs' combat effectiveness?). 
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SITUATION BASELINE 


SHIPS 
FFG-7 Krivak II 
Dimensions 
L 135m 23.4m 
B io 7 Ml 14.0m 
H 30m Bom 
Propulsion 
41,000shp gas turbine 80,000shp gas turbine 
Speed 
30kts 32 kts 
Helicoptors 
2x SH-2 (+) (300kts/100mn) None 
Weapons 
Guns 
1. 1x 77mm (86rpm/i6km range) 2x 100mn ( ?rpm/ ?rai 


2. 1 30mm close in weapon 


Torpedos 
HOS 





2x 3 tubes 


Missiles 


MKi3 standard (AA/anti surface) 
(10nm/55nm) 


ASW Weapons 


Sonar 
SQOS-56 (medium frequency) 


TACTAS (pasSive array) 


8 tubes 


SSN -14 (21 onin) 


SAN 4 (8mn) 


2 ASW mortars 


Hull (Medium/low frequency) 
Variable depth sonar 


(Medium frequency) 


Electronics 
Radar 
Alrsearch 
SPS49 HEAD NET "Cc" 
Surface Nav 
SPS 55 DON-2 


Fire control (Gun) 
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SPG-60 (Missile). 


Other Forces in Company 


none 


Weather 


Winds- 10 kts (from north) 


Seas - 3-4ft (n) 


wisi bility - i3nm 


Precipitation - none 


Jamming - none 


Kitescreech (Guns) 
EYE Bowl SSN-14 
POP Group SAN~-4 


(from threat/environment section 1A) 


none 
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EQUIPMENT IN OPERATION/SIGNATURES 


BEG / 


Primary Mission 


(AAW Advance Escort) 


Propulsion i6kts (patrol) 


SENSORS 


Sonars 


SQS-56-passive 


Tactas - deployed 


Active Radars 


49-A radiating/timeshare 


aoe >) radiating 


Missile/gun radar- standby 


ECM 


Auto search (passive) 


Krivak II 


Primary Mission 


(ASW Patrol) 


12kts (> cavitation speed) 


Hull mounted - passive 


Variable depth - active 


Head net C - standby 
Don-2 radiating 


Missile/gun radar - standby 


Search passive 
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Communications UHF/HF - 


EMCON (receive only) UHF /HF-EMCON (Receive only) 


(No short range communication techniques (visual horizon) 


due to single ship operations by both sides.) 


109 





Chapter 8 


CONCLUSIONS 


This project offers "sometime original” by introducting 
a high level objective function: combat effectiveness: at 
the feasibility level of the ship design process. It fur- 
ther allows all participants to the process access to the 


assumptions used to arrive at that objective function. 


As discussed in chapter 1, the project team feels that 
the time is ripe to bring combat effectiveness into the ship 
design process. Improvements in gaming techniques and mod- 
eling have improved the ease of including combat effective- 
ness within the design process at the preliminary design 
Stage. While it is a fact that there are potential improve~ 
ments to many other facets of the process to be made by this 
approach, inclusion of the considerations raised by combat 
and combat operations should prevent over emphasis or out 
right suboptimization upon the noncombat considerations. 
The attributes and potential flexibility of DEX (see chapter 
2) are extremely important. The complexity of the ship 
design process demands maximum integration of the model and 
the user. It is believed that specification of the means or 
equipment too early in the process should be avoided. Such 
premature definition of hardware is a potential disruption 
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to the total process. In effect it 1s something done, in 
many cases, too early and it 1s the remaining portions of 
the design which suffer. In effect, when equipment is spec- 
ified to satisfy a need too early in the process, it may 
well be that the totality of its impact upon other later 
design stages may be missed. This model is believed to be a 
major attempt to include all significant determinants of 
naval vessel characteristics. Eventually all design proc- 
esses will, conceivably, be addressed by such a systems 
approach. The author feels that the techniques exist to 
permit this effort in the admittedly complex and involved 
ship design process. All the techniques proposed in this 
model ars in practice, it is the integration of them under a 
capable software system which is a major contribution of 


Ehesmmao ject. 


The impact of weapons/sensor performance upon ship 
design, is reflected in the sensitivity of the combat effec- 
tiveness of the design to them. The combat effectiveness 
figures and algothrims from chapter 7 are, therefore, a 
Starting point for the ship systems designer. If they rep- 
resent important, even vital Gonecdoutsons to the 
effectiveness of a ship in combat, their accuracy 1s crit- 
ical. The authors believe that the naval architect/marine 
enginee’ must become actively involved in the determination 
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and validation of any such techniques used to drive the 
design process. It 1S believed that such algorithms are 
extremely sensitive to minor variations in the system con- 
figurations. It will be one essential task of the naval 
architect/marine engineer of the future to provide the sci- 
entific interaction between such causes and their effects. 
It is this person who might, for example, best model a con- 
ceptual weapons effect upon an assumed hull structure to 
provide a curve such as the damage assessment curve (like 


figure CE 3). 


The framework for a future naval ship design process mod- 
el has been presented. It will require validation and 
refinement. The next step in this project will be the 


development of the modules to support the framework. 
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 APPENDIZ 


This appendix consists, in order, of the menu all devel- 
oped menu Strings listed below. The numbers refer to the 


Sections defined in figure i, chapter 1. 
Threat/Environment (1a) Surface Threats (pages lali-i 
through 1a1-22) 


Non Combat Environment (1b) Command Control and Communi- 


cation (pages ibi-i through 1b1-14) 


Platform Parameters (3) Signatures (pages 3a-1 through 


Smet) 


Platform Parameters (3) Risk Factors (pages 3b-i1 through 


Ses) 
Combat Effectiveness (7) All (pages 7-1 through 7-7) 


Fach menu section consists of a title page, a mapping of 


the section and pages of 1 to 4 specific menus. 





Six menus have been left blank for the application pro- 


Grammer in these ares to insert the appropriate information. 


For readability purposes, the eight letter abbreviations 


required by DEX have not been used in this appendix. 
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